Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-131.txt

Text File | 1994-12-08 | 40.2 KB | 1,154 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 03 Jul 92       Volume 1 : Issue 131

Today's Topics:

    SCSI Device Type Codes?
    Comparing blocks of memory in Think Pascal 4? How?
    Not So Amusing MPW C v3.2 Error Messages
    Ridiculous MemoryMgr Problem
    Globals, A5, and all that stuff...
    Dumb THINK C Projects!
    Apple Modem Tool 1.1 Bugs?
    Moving windowws
    Unet.Mac.Pgm.Guide in PostScript available for FTP
    Launching from a code resource, revisited...
    _Datainit() : what does it do & where does it do it?



-------------------------------------------------------

From: [e-mail] (R. Munroe)
Subject: SCSI Device Type Codes?
Organization: UTCS Public Access
Date: Sun, 31 May 1992 07:36:55 GMT


Does anyone have a complete list of SCSI type codes (as returned by
a standard SCSI inquiry command)?  I think that hard disks are 0, tape
drives are 1, and CD-ROMS are 5, but beyond that I'm clueless.

Thanks.

Bob

- --
John Mariella                             :Internet:   [e-mail]
Animation Director
TOPIX Computer Graphics + Animation, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Maarten Carels)
Date: 1 Jun 92 08:20:42 GMT
Organization: FWI, University of Amsterdam

[e-mail] (R. Munroe) writes:


>Does anyone have a complete list of SCSI type codes (as returned by
>a standard SCSI inquiry command)?  I think that hard disks are 0, tape
>drives are 1, and CD-ROMS are 5, but beyond that I'm clueless.

An almost complete list:
     0    Disk
     1    Tape
     2    Printer
     3    Processor
     4    WORM Device
     5    CD-ROM Device
     6    Scanner
     7    Optical Memory
     8    Medium Changer
     9    Communication Device
    10    ASC IT8 (Whatever that may be)
    11    ASC IT8 (Whatever that may be)
        Other values reserved.


- --maarten
- --
In real life:    Maarten Carels
        Computer Science Department
        University of Amsterdam
email:        [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ephraim Vishniac)
Date: 1 Jun 1992 14:04:10 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA

In article <[e-mail]> [e-mail] (Maarten Carels) writes:
>[e-mail] (R. Munroe) writes:
>>Does anyone have a complete list of SCSI type codes (as returned by
>>a standard SCSI inquiry command)?  I think that hard disks are 0, tape
>>drives are 1, and CD-ROMS are 5, but beyond that I'm clueless.

>An almost complete list:
>     0    Disk
>     1    Tape
>     2    Printer
>     3    Processor
>     4    WORM Device
>     5    CD-ROM Device
>     6    Scanner
>     7    Optical Memory
>     8    Medium Changer
>     9    Communication Device
>    10    ASC IT8 (Whatever that may be)
>    11    ASC IT8 (Whatever that may be)
>        Other values reserved.

The SCSI-2 spec says:

00h    Direct-access device (e.g., magnetic disk)
01h    Sequential-access device (e.g., magnetic tape)
02h    Printer device
03h    Processor device
04h    Write-once device (e.g., some optical disks)
05h    CD-ROM device
06h    Scanner device
07h    Optical memory device (e.g., some optical disks)
08h    Medium changer device (e.g., jukeboxes)
09h    Communications device
0Ah - 0Bh    Defined by ASC IT8 (Graphics Arts Pre-Press Devices)
0Ch - 1Eh    Reserved
1Fh    Unknown or no device type

These official descriptions are slightly more inclusive than the ones
that Maarten gave. For example, a box full of solid-state memory isn't
a disk, but it could easily be a direct-access device.

- --
Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.

---------------------------

Subject: Comparing blocks of memory in Think Pascal 4? How?
From: [e-mail] (Nigel Stanger)
Date: 1 Jun 92 16:58:45 +1300
Organization: University of Otago, Dunedin, New Zealand

Is there any way of comparing two arbitrarily (but equal) sized
blocks of memory in Think Pascal? What I have is a RECORD
(PrefsType) that I store my apps preferences in -- it's currently
26 bytes long, but may get bigger later on. Now since you can't
just say: IF (prefs1 = prefs2) THEN..., I had to write a routine
to check whether two PrefsType records are identical. ('=' in TP
only lets you compare simple types, not structures.)

Now, given that I have to individually compare about 13 different
fields in the record, I thought it would be nice to just directly
compare the two records as blocks of memory (or something like
that). I played around with type-casting, but nothing worked
there (because the only way I could get something with a size of
26 bytes was to make it a structured type, and I was back where I
started). Then I tried this:

FUNCTION Identical (item1, item2 : UNIV Ptr) : Boolean;
BEGIN
  IF (item1^ = item2^) THEN
    Identical := TRUE
  ELSE
    Identical := FALSE;
END;

  IF Identical(@prefs1, @prefs2) THEN ...

Of course, this didn't work because a Ptr is a pointer to a
SignedByte, so only the first byte of the record was getting
compared -- it just so happens that the first byte is the version
number of the preferences structure and is always identical in
both of them no matter what. I tried mucking around with
SetPtrSize, but that didn't work either.

I think this would be fairly trivial in C, but I don't have C yet
:( Any suggestions on what I could try next? I've run out of
ideas. Inline assembler perhaps? Or something simpler that I'm
missing? Thanks!

- --
See ya
                                Nigel.
- ----------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
"And whatever you do, don't mention the War." -- Basil Fawlty, "Fawlty Towers"

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 1 Jun 92 15:52:58 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Nigel Stanger) writes:
>Is there any way of comparing two arbitrarily (but equal) sized
>blocks of memory in Think Pascal? What I have is a RECORD
>(PrefsType) that I store my apps preferences in -- it's currently
>26 bytes long, but may get bigger later on. Now since you can't
>just say: IF (prefs1 = prefs2) THEN..., I had to write a routine
>to check whether two PrefsType records are identical. ('=' in TP
>only lets you compare simple types, not structures.)

Try:

IUMagIDString(aPtr,bPtr:Ptr;aLen,bLen:INTEGER):INTEGER;

It will compare blocks of memory and return a 0 if they are equal else
it return a 1.

Look at IM vol 1 507;


There are some other routines that do something similar.




Matt




- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Tue, 2 Jun 1992 01:37:35 GMT

In article <[e-mail]>, [e-mail] (Nigel Stanger) writes:
>
> Is there any way of comparing two arbitrarily (but equal) sized
> blocks of memory in Think Pascal? What I have is a RECORD
> (PrefsType) that I store my apps preferences in -- it's currently
> 26 bytes long, but may get bigger later on. Now since you can't
> just say: IF (prefs1 = prefs2) THEN..., I had to write a routine
> to check whether two PrefsType records are identical. ('=' in TP
> only lets you compare simple types, not structures.)
>
> Now, given that I have to individually compare about 13 different
> fields in the record, I thought it would be nice to just directly
> compare the two records as blocks of memory (or something like
> that).

A word of caution for the uninitiated.  If you're already familiar
with record packing then please feel free to ignore my ravings.

The reason Pascal doesn't support comparing structured types is that
not all the bits in a record or array are necessarily significant.
For example:

type
  a =
    record
      b : boolean;
      c : char;
      d : boolean;
    end;

Acording to Think Pascal this has a size of 6.  Now there are only
3 bytes of real data in there so you're left with 3 bytes of rubbish.
If you do a memory image compare you're going to be mislead, if
not now then some time soon.

Of course if you stick to nice types like integer, longint, OSType,
etc (things that are word sized or even multiples thereof) you'll
be OK.  Things to be careful of are char, byte, signedByte, boolean,
subranges, and arrays.  Also remember that if you make your records
packed then all these rules change!

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Careful With That Axe, Eugene!


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 2 Jun 92 18:57:15 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Matt Mora) writes:

   Try:

   IUMagIDString(aPtr,bPtr:Ptr;aLen,bLen:INTEGER):INTEGER;

   It will compare blocks of memory and return a 0 if they are equal else
   it return a 1.

Ahem. That "IU" means that it will do some strange stuff with
international characters...

- --
h++ - new and improved ! And now on VACCATION !!!
(My first for, oh, three years !)

---------------------------

From: [e-mail] (Matthias Neeracher)
Subject: Not So Amusing MPW C v3.2 Error Messages
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 1 Jun 1992 09:58:24 GMT

In article <[e-mail]> [e-mail] (Alan J Rosenthal) writes:

>Can't cast a void type to type void (because the ANSI spec. says so, that's why)

The not so amusing aspect of this error message is that it is PLAIN WRONG.
An authoritative source on comp.std.c quoted the ANSI standard as follows:

ANSI 3.2.2.2, first sentence:
# "The (nonexistent) value of a void expression (an expression
# that has type void) shall not be used in any way, and implicit or explicit
# conversions (except to void) shall not be applied to such an expression."

So, while this error message is cute, it is *wrong*, and there is no reason for
the compiler to give it, and it OUGHT TO BE REMOVED.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 1 Jun 1992 20:24:27 GMT

[e-mail] (Matthias Neeracher) writes:
>[e-mail] (Alan J Rosenthal) writes:
>
>>Can't cast a void type to type void (because the ANSI spec.
>>says so, that's why)
>
>The not so amusing aspect of this error message is that it is PLAIN WRONG.
>ANSI 3.2.2.2, first sentence:
> "The (nonexistent) value of a void expression (an expression
> that has type void) shall not be used in any way, and implicit or explicit
> conversions (except to void) shall not be applied to such an expression."

K&R, 2nd ed., agrees:  "The (nonexistent) value of a void object may not
be used in any way, and neither explicit nor implicit conversion to any
NON-VOID type may be applied." (my emphasis)

So what's up, O MPW C Compiler Writer?  Not that this is at all important.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Always set the version number that appears in some file manager calls to 0.

---------------------------

From: [e-mail] (Don Gillies)
Subject: Ridiculous MemoryMgr Problem
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 1 Jun 1992 09:58:59 GMT

I am having a ridiculous problem with the memory manager.  I am using
THINK C 4.02, on a 5 Meg macintosh II with system 7.0.  My application
needs about 600K of the heap, and ~ 40K of stack.  I made the
partition 1150K and tried the following:

    SetZone(ApplicZone());
    printf("limit is %ld\n", GetApplLimit());    /* prints 2929K */
    printf("free is %ld\n", FreeMem());        /* prints 909K */
    newlimit = GetApplLimit() - 40000L;        /* is 2889K */
    SetApplLimit(newlimit);                /* crash here */
    printf("free is %ld\n", FreeMem());
    MaxApplZone();

The above code crashes in the "SetApplLimit" call.  The symptom of the
crash is that the screen erases and all the windows lose their
borders, and only the top-level window will appear on the screen
(without border).  All the other windows look like ghostly shadows,
and the finder seems to still be operating o.k., but because of the
ghostly windows, it is impossible to do useful work.

The code used to work if the newlimit was 10000L less than
GetApplLimit, but otherwise, it would not work.  Now I am using the
following code:

    SetZone(ApplicZone());
    printf("limit is %ld\n", GetApplLimit());
    printf("free is %ld\n", FreeMem());        /* 909K */
    newlimit = GetApplLimit() - 40000L;
/*    SetApplLimit(newlimit); */
    ApplLimit = newlimit;
    printf("free is %ld\n", FreeMem());        /* 909K - 10 */
    MaxApplZone();

This seems to work, but the amount of "FreeMem()" does not decrease
after I decrement the global variable "ApplLimit".  (it decreases by a
very small amount, presumably because of the "printf" command).  This
worries me.  Does anyone know what is the problem?  It seems like
"SetApplLimit" is flakey in this version of THINK C.  It seems like
assigning to the "ApplLimit" global variable does not adequately
inform the memory manager of the change in the application heap size.

Don Gillies - [e-mail] - University of Illinois at Urbana-Champaign


- --




+++++++++++++++++++++++++++

From: [e-mail] (Don Gillies)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 1 Jun 1992 19:39:35 GMT

Oops, I made a mistake in describing the crash.  The problem is, as
soon as I call one or two subroutines with a large number of local
vars (~5K each) (i.e.  more than 8K of vars are on the stack -- the
default stack size, according to IM II), I get either get "Stack
Collision with Heap" or the window system goes crazy, as described
before.

huge is not NIL -- I have convinced myself that it is being allocated
correctly (the constant involved is (252^2) * 2 * 5 = 635040, a long).
I get the impression that "SetApplLimit" is somehow not increasing the
space for the stack.  I don't know why the space for the stack is not
increasing.  It seems that the only way to increase space for the
stack is to set the global variable "ApplLimit".

Don Gillies - [e-mail] - University of Illinois at Urbana-Champaign


- --




+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 2 Jun 92 01:34:42 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Don Gillies) writes:
>
> I am having a ridiculous problem with the memory manager.  I am using
> THINK C 4.02, on a 5 Meg macintosh II with system 7.0.  My application
> needs about 600K of the heap, and ~ 40K of stack.  I made the
> partition 1150K and tried the following:
>
>     SetZone(ApplicZone());
>     printf("limit is %ld\n", GetApplLimit());    /* prints 2929K */
>     printf("free is %ld\n", FreeMem());        /* prints 909K */
>     newlimit = GetApplLimit() - 40000L;        /* is 2889K */
>     SetApplLimit(newlimit);                /* crash here */
>     printf("free is %ld\n", FreeMem());
>     MaxApplZone();
>
> The above code crashes in the "SetApplLimit" call.  The symptom of the
> crash is that the screen erases and all the windows lose their
> borders, and only the top-level window will appear on the screen
> (without border).  All the other windows look like ghostly shadows,
> and the finder seems to still be operating o.k., but because of the
> ghostly windows, it is impossible to do useful work.
>
> The code used to work if the newlimit was 10000L less than
> GetApplLimit, but otherwise, it would not work.  Now I am using the
> following code:
>
>     SetZone(ApplicZone());
>     printf("limit is %ld\n", GetApplLimit());
>     printf("free is %ld\n", FreeMem());        /* 909K */
>     newlimit = GetApplLimit() - 40000L;
> /*    SetApplLimit(newlimit); */
>     ApplLimit = newlimit;
>     printf("free is %ld\n", FreeMem());        /* 909K - 10 */
>     MaxApplZone();
>
> This seems to work, but the amount of "FreeMem()" does not decrease
> after I decrement the global variable "ApplLimit".  (it decreases by a
> very small amount, presumably because of the "printf" command).  This
> worries me.  Does anyone know what is the problem?  It seems like
> "SetApplLimit" is flakey in this version of THINK C.  It seems like
> assigning to the "ApplLimit" global variable does not adequately
> inform the memory manager of the change in the application heap size.


It works for me.  I can use this code, without the printf, just fine.

The interfaces for the routines you need are as follows:

#define GetApplLimit() (* (Ptr*) 0x0130)

pascal void SetApplLimit(void *zoneLimit)
    = 0xA02D;

These are simple enough and shouldn't be causing you any problems.

You certainly need to use SetApplLimit since it does more that just
adjust the low memory global ApplLimit.  If SetApplLimit is crashing,
you could have a trashed heap (try HC in MacsBug before calling
the SetApplLimit).  The location you're pointing to may be too low
that it points into your heap.  FreeMem may not change just because
you're changing the lower limit of the stack, since the heap may have
not been expanded yet.  To find out a better approximation of possible
free bytes you'll have to call MaxApplZone but that has to happen after
you adjust the stack.

> It seems like
> assigning to the "ApplLimit" global variable does not adequately
> inform the memory manager of the change in the application heap size.

Yup, that's what I'm saying.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Don Gillies)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 2 Jun 1992 05:49:20 GMT

[e-mail] (Jim Reekes) writes:

>It works for me.  I can use this code, without the printf, just fine.
>The interfaces for the routines you need are as follows:

>#define GetApplLimit() (* (Ptr*) 0x0130)

>pascal void SetApplLimit(void *zoneLimit)
>    = 0xA02D;

>These are simple enough and shouldn't be causing you any problems.
>-----------------------------------------------------------------------
>Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
>                             |          Sound Manager Expert
>Apple Computer, Inc.         | "All opinions expressed are mine, and do
>20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
>Cupertino, CA 95014          |       employer, Apple Computer Inc."


Thanks, this helped me to solve the problem.  I assume it was a either
from bringing up the THINK C console and using printf() (which seems
to allocate memory) before readjusting the heap size, or it was
because I shouldn't have relied on the THINK C definition of
SetApplLimit ( THINK C was not complaining with "check prototypes"
turned on -- I assumed the compiler was understood the SetApplLimit
call ).  Thanks to everyone who sent me email responses!

Don Gillies - [e-mail] - University of Illinois at Urbana-Champaign


- --




+++++++++++++++++++++++++++

From: [e-mail] (Dave Ely)
Date: 2 Jun 92 03:32:34 GMT
Organization: Symantec / Peter Norton

[e-mail] (Don Gillies) writes:
> I am having a ridiculous problem with the memory manager.  I am using
> THINK C 4.02, on a 5 Meg macintosh II with system 7.0.  My application
> needs about 600K of the heap, and ~ 40K of stack.  I made the
> partition 1150K and tried the following:
>
>     SetZone(ApplicZone());
>     printf("limit is %ld\n", GetApplLimit());    /* prints 2929K */
>     printf("free is %ld\n", FreeMem());        /* prints 909K */
>     newlimit = GetApplLimit() - 40000L;        /* is 2889K */
>     SetApplLimit(newlimit);                /* crash here */
>     printf("free is %ld\n", FreeMem());
>     MaxApplZone();
>

Calling printf before doing the SetApplLimit is probably what's
causing all of your problems. Think loads the ANSI segment,
initializes several managers, sets up a new window and all of it's
associated structures. SetApplLimit needs to be called as early as
possible, certainly before initializing anything and almost certainly
before loading other segments. You might want to try something like
this...

void main( void )
{
#define        kStackToUse    0x0000A000    /* 40K */
ulong        stack_bottom;
ulong        heap_top;

    heap_top = (ulong)ApplLimit;
    asm {
        move.l    a7, stack_bottom
        }

    /* move heap down, make stack larger */
    heap_top = stack_bottom - kStackToUse;
    SetApplLimit( (Ptr)heap_top );

    /* expand the zone to max size */
    MaxApplZone();

    etc. ...

}

Before doing the SetApplLimit you should probably also preflight the
current zone and make sure it's big enough for your purposes.

- --
 ______________________________________________________________
    Dave Ely                    | Internet:  [e-mail]
    Symantec/Peter Norton Group | AppleLink: Ely.D

---------------------------

From: [e-mail] (Chris Wright)
Subject: Globals, A5, and all that stuff...
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 1 Jun 1992 12:12:37 GMT

I understand, (I hope :-)), why one can't define A5 relative globals in
stand alone code ('cos they'd clobber the applications globals), and I'm
led to believe that at interrupt time (such as VBI tasks), you can't trust
ANYONE, and A5 could point at your grandmother's walking stick, but I'm
not clear on why - in say an XCMD - one can't refer to the QD globals.
I would have thought that A5 was still pointing at the boundary b/n tha
app parameters and globals, and we all know what's -4(A5).

Could some one please help me?

Thanks,

chris

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jun 92 18:28:00 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Chris Wright)
writes:
>
> I understand, (I hope :-)), why one can't define A5 relative globals in
> stand alone code ('cos they'd clobber the applications globals), and I'm
> led to believe that at interrupt time (such as VBI tasks), you can't trust
> ANYONE, and A5 could point at your grandmother's walking stick, but I'm
> not clear on why - in say an XCMD - one can't refer to the QD globals.
> I would have thought that A5 was still pointing at the boundary b/n tha
> app parameters and globals, and we all know what's -4(A5).

Who says you can't refer to QD globals? Any time you make a call to something
like GetPort() or Random(), you are referencing those globals.

> and we all know that's -4(A5).

DO NOT assume this is true! This is dependent on the implementation of the
linker (see technote #208). (A5) points to the "thePort" field of the QD globals
record. Work from that.

BTW: Check out Technote #256 for issues on using A5 in standalone code. There
will also be an article in the next "develop" magazine (or the one after) that
offers a new way of using A5 in standalone code under MPW.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jun 92 18:33:32 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
>
> DO NOT assume this is true! This is dependent on the implementation of the
> linker (see technote #208). (A5) points to the "thePort" field of the QD
globals
> record. Work from that.

Of course, when I say technote #208, I really mean #223.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Dave Newman)
Date: 3 Jun 92 00:16:53 GMT
Organization: Notable Technologies, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Chris Wright) writes:
| I understand, (I hope :-)), why one can't define A5 relative globals in
| stand alone code ('cos they'd clobber the applications globals), and I'm
| led to believe that at interrupt time (such as VBI tasks), you can't trust
| ANYONE, and A5 could point at your grandmother's walking stick, but I'm
| not clear on why - in say an XCMD - one can't refer to the QD globals.
| I would have thought that A5 was still pointing at the boundary b/n tha
| app parameters and globals, and we all know what's -4(A5).
|
| Could some one please help me?

You may want to find a copy of the paper that Allan Foster and I wrote
for last year's MacHack on this subject. Along with this paper we
released to the public domain a runtime library to aid things like
XCMD's in their use of A5, mutli-segmenting, C++ support, etc. This
also included a MPW tool that performed a post-link operation on an
application to turn it into standalone code. (i.e. you compile and
link your XCMD as if it were an application and the post-link tool
turns it into an single or mutli-segmented standalone code resource.)

- --Dave

PS - The paper, runtime library, post-link tool and their sources
should be on both CIS and AOL. Since I have no ftp capabilities, I
can't see if they made it into places like Sumex.

- -----------------------------------------------------------
Dave Newman                 |  AOL:      AFC Tinman
Artillery Spotter           |  CIS:      70743,3323
Notable Technologies, Inc.  |  internet: [e-mail]
510.208.4449                |  FAX:      [phone]
- -----------------------------------------------------------

---------------------------

From: [e-mail] (Joe Zobkiw)
Subject: Dumb THINK C Projects!
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 1 Jun 1992 12:51:03 GMT

I download a THINK C project with all source. I go to compile it and
it can't find the first file! I put the source files in the same
folder as the project file. Still, no go. I resort to removing all
project files and re-adding them. A royal pain.

Does anyone have a solution (ie: a hack) to fix this shortcoming
in THINK C?






- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Eric K. Olson)
Organization: Whitehead Institute for Biomedical Research
Date: Mon, 1 Jun 1992 17:10:16 GMT

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
>I download a THINK C project with all source. I go to compile it and
>it can't find the first file! I put the source files in the same
>folder as the project file. Still, no go. I resort to removing all
>project files and re-adding them. A royal pain.
>
>Does anyone have a solution (ie: a hack) to fix this shortcoming
>in THINK C?
>

Open the "Make" dialog, uncheck the "Quick Scan" checkbox, and
click on "Use Disk."

Cheers!

- -Eric




---------------------------

From: [e-mail] (Joe Zobkiw)
Subject: Apple Modem Tool 1.1 Bugs?
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 1 Jun 1992 12:55:25 GMT

Needless to say I'm implementing an application in THINK C 5.02 that
uses the Connection Manager. Every tool I've used seems to work fine
except for the Apple Modem Tool 1.1. Whenever I select this tool and
click OK or Cancel in its configuration dialog, I crash! It seems I
bomb in a ctmb (or is it cmtb? no code in front of me) and the THINK C
Debugger points me right in my main event loop after my MouseDown handler.

I'm at a loss. This is on a IIcx with a Radius Rocket and 8 megs RAM.
7.0.1 in 32 bit mode with the latest Tuner. Any ideas? Is the AMT still
as buggy as it was before they fixed it?





- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm   CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Paul G. Smith)
Date: 1 Jun 92 19:46:23 GMT
Organization: CommsTalk HQ


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Joe Zobkiw) writes:
> I'm at a loss. This is on a IIcx with a Radius Rocket and 8 megs RAM.
> 7.0.1 in 32 bit mode with the latest Tuner. Any ideas? Is the AMT still
> as buggy as it was before they fixed it?
>

Try AMT version 1.1.1, which is now up on AppleLink. I don't know if
it's on ftp.apple.com; I don't have ftp access so I can't check.

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

---------------------------

From: [e-mail] (Brad Morris)
Subject: Moving windowws
Organization: University of Chicago Computing Organizations
Date: Mon, 1 Jun 1992 13:43:53 GMT

I would like my app to have windows appear where they were when the program
was last used.  I was not going to change the WIND resource because it is
useful to have this as the default just in case the program is moved to
a machine with a smaller screen.  What is the method for this?  I have
tried using the window's regions bounding box to store an upper left and
moving the window using the move command but the window keeps jumping to
weird spots (title bar under the menu bar).  Thanks.

Brad Morris
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Brad Morris)
Organization: University of Chicago Computing Organizations
Date: Tue, 2 Jun 1992 13:18:42 GMT

I have solved the problem.  I am now creating a 0,0 point, setting the port
to the window I want to save, and converting the point from local to global.
When my app is run, it tries to move the window if the point lies in the
screen rect.  Thanks for those that replied.

---------------------------

From: [e-mail] (Nasir Ahmed Noor)
Subject: Unet.Mac.Pgm.Guide in PostScript available for FTP
Organization: University of Manitoba, Winnipeg, Canada
Date: Tue, 2 Jun 1992 15:16:37 GMT



Hi,
The Usenet Macintosh Programming Guide (in PostScript format) is now
available for FTP at
      ccu.umanitoba.ca
      /pub/mac
         (usual ftp way to logg in).

The file is over 850k in size. Its uuencoded and compressed with zip. I can
also make it available in unix compress (.Z) if quite a few people dont
have access to "unzip" (contact me). The complete Guide is over 325 pages
long (this is for those who have 200 page limit on their accounts).

You can contact me if you have any questions regarding this.

Regards,
Nasir Ahmed Noor
[e-mail]

p.s. If your site does not have FTP facility available and you want me to
     'mail' a copy to you, please make sure your account can handle a mail
      larger than 200k.
p.p.s This guide in PostScript format is not of any use if you dont have
      access to PostScript printer.

+++++++++++++++++++++++++++

From: [e-mail] (Nasir Ahmed Noor)
Organization: University of Manitoba, Winnipeg, Canada
Date: Wed, 3 Jun 1992 00:03:38 GMT



I have made available a copy in .Z format in the same directory for
ftp. Please report any problems.

Nasir Ahmed Noor
[e-mail]

---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: Launching from a code resource, revisited...
Date: 2 Jun 92 16:11:31 GMT
Organization: U of Wisconsin-Madison College of Engineering

Our story so far:
A while back, I posted asking how to launch an app from an INIT.  Thanks to
the vigilance and helpfulness of several netters, I was informed that my
terminology was in error, and what I really wanted to do was to launch from
the code resource that is the trap patch that the INIT installs, and I was
pointed toward IM-VI, ch. 29 and TN 126.

Okay, so I've got this patch to _Control that watches for a NetWare volume
to be mounted, does some stuff, and is then supposed to launch an app.  I've
read through the IM-VI and TN 126 stuff on launching.  It mostly makes sense
to me.  I think I can handle it, except for one thing...


The Rub:
At the end of the patch is the usual:
asm
{
    move.l pb,a0        /* restore original passed pb */
    movem.l (sp)+,a2-a3/d0-d7    /* restore our saved registers */
    unlk a6            /* undo what the compiler does for you */
    jmp (a1)        /* jump to old routine */
}

Now, I either have to launch the app before this, and then when the app is
done, return to jump to the original _Control trap, i.e. a sublaunch, or
I have to jsr to the original routine, and then after I return from that,
launch the app, i.e., a tail patch (actually, a combination head/tail patch,
if I leave the rest of the patch where it is).

>From what I understand, both of these are frowned upon.  My question is,
which is the lesser of two evils, or, is there a better way that I'm completely
missing?

My thinking is that the tail patch would be preferable to the sublaunch, if
for no other reason than that sublaunches seem to be even more strongly
discouraged in the literature than tail patches.  If I do go with the tail
patch, is it okay to leave the head patch in place?

Any advice on this is *greatly* appreciated.


Thanks,
Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Wed, 3 Jun 1992 02:48:33 GMT

[e-mail] (Jeffrey Verdegan) writes:

>The Rub:
>At the end of the patch is the usual:
>asm
>{
>    move.l pb,a0        /* restore original passed pb */
>    movem.l (sp)+,a2-a3/d0-d7    /* restore our saved registers */
>    unlk a6            /* undo what the compiler does for you */
>    jmp (a1)        /* jump to old routine */
>}

First, I would save A1 as well since this is an OS Trap, put the
address of the old routine on the stack, and RTS. That way you don't
use any registers. But as for the rest......

>Now, I either have to launch the app before this, and then when the app is
>done, return to jump to the original _Control trap, i.e. a sublaunch, or
>I have to jsr to the original routine, and then after I return from that,
>launch the app, i.e., a tail patch (actually, a combination head/tail patch,
>if I leave the rest of the patch where it is).

Better idea: Post a Notification with the nmStr, nmIcon, nmSound, and
nmMark all set to 0 and the nmResp set to a routine that will launch
the application. Very safe, guaranteed to be executed at non-interrupt
or other nasty times, and you don't have to worry about saving
registers, etc. And no slowing down the real operation of the _Control
or need to do any tail patching. Very neat.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

From: [e-mail] (Steven D. Majewski)
Subject: _Datainit() : what does it do & where does it do it?
Organization: University of Virginia - Physiology Dept.
Date: Tue, 2 Jun 1992 17:13:48 GMT

HELP

I keep getting an error from MPW Link :
"Global data used ...   _Datainit() not called..."
( not exactly but close enough, I hope. )

Other than a single non-helpful reference in the MPW release notes,
I can't find anything about this routine in the indexes ( MPW or MPW-C ).
I've also looked up all the entries for 'extern' in MPW C, but still no
clues.

What does _Datainit() do?
When & how should it be called?

I *guess* since I can't find instructions for that routine in the
manual, that it is NOT meant to be a user level call - i.e. there
is probably some OTHER routine that is supposed to call _Datainit(),
and THAT routine is not being called ( perhaps missing some linker
directive ? )

Any help or clues will be appreciated!
Thanks,
 Steve Majewski


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831/32    1300 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 2 Jun 92 19:30:14 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Steven D. Majewski) writes:
>
> HELP
>
> I keep getting an error from MPW Link :
> "Global data used ...   _Datainit() not called..."
> ( not exactly but close enough, I hope. )
>
> Other than a single non-helpful reference in the MPW release notes,
> I can't find anything about this routine in the indexes ( MPW or MPW-C ).
> I've also looked up all the entries for 'extern' in MPW C, but still no
> clues.
>
> What does _Datainit() do?
> When & how should it be called?
>
> I *guess* since I can't find instructions for that routine in the
> manual, that it is NOT meant to be a user level call - i.e. there
> is probably some OTHER routine that is supposed to call _Datainit(),
> and THAT routine is not being called ( perhaps missing some linker
> directive ? )

_DataInit is used to initialize your global variables. The exact steps it takes
are documented in Technote #240. However, it is likely that Technote #256 will
be more helpful to you. People usually get that error message when they are
creating standalone code that attempts to access global variables. Technote #256
addresses this problem explicitly.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 2 Jun 92 20:01:40 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Steven D. Majewski) writes:
>
> HELP
>
> I keep getting an error from MPW Link :
> "Global data used ...   _Datainit() not called..."
> ( not exactly but close enough, I hope. )
>
> Other than a single non-helpful reference in the MPW release notes,
> I can't find anything about this routine in the indexes ( MPW or MPW-C ).
> I've also looked up all the entries for 'extern' in MPW C, but still no
> clues.
>
> What does _Datainit() do?
> When & how should it be called?
>
> I *guess* since I can't find instructions for that routine in the
> manual, that it is NOT meant to be a user level call - i.e. there
> is probably some OTHER routine that is supposed to call _Datainit(),
> and THAT routine is not being called ( perhaps missing some linker
> directive ? )

You have probably used a string constant in your code.  This means
that the compilier will collect this data into a segment that is meant
for use as an A5 offset.  All of your strings are allocated into the
global data space.  The compiler will automatically call the routine
DataInit to allocate and initialize this data.  You have to LINK with
Runtime.o to get this routine.

If you're writing stand alone code that does not have a global A5
data space, then you can have your strings compiled directly into your
code space by using the -b option for the C compilier.

If you look at the sample code that comes with MPW you'll find that it
will unload the DataInit code segment.  Since this code is automatically
supplied into it's own segment, you need to unload it too.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

---------------------------

End of C.S.M.P. Digest
**********************